Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@app/views/ScreenLockConfigView.test.tsx`:
- Around line 108-122: The rollback test in ScreenLockConfigView only checks
that autoLock is reset, so it can miss stale timeout state after cancel. Update
the test around mockWrite/update in ScreenLockConfigView.test.tsx to also assert
the persisted record includes the default auto-lock duration from save(false,
DEFAULT_AUTO_LOCK), alongside the existing autoLock false check.
- Around line 16-22: The `useAppSelector` mock contracts in
`ScreenLockConfigView.test.tsx` are using `any`, which bypasses the
`IApplicationState` shape enforced by `useAppSelector`. Update the mocked
selector signatures in the test cases that stub `useAppSelector` to accept
`IApplicationState` instead of `any`, and keep the mocked state object typed
consistently with `server` and `settings` so drift is caught by TypeScript.

In `@app/views/ScreenLockConfigView.tsx`:
- Around line 75-82: The local screen-lock state in ScreenLockConfigView is
being initialized from the user server record even when Force_Screen_Lock is
enabled, which can leave autoLock false and hide the enforced duration UI.
Update the initialization in useEffect (and any dependent render logic for the
rows around the autoLock/autoLockTime controls) to derive state from the
effective forced screen-lock setting instead of raw serverRecord.current values,
so the switch and duration rows reflect the enforced configuration.
- Around line 103-143: The async UI handlers in ScreenLockConfigView should not
allow rejected promises to escape. Wrap toggleAutoLock and handleChangePasscode
in explicit try/catch so checkHasPasscode, handleLocalAuthentication,
changePasscode, and save failures are handled locally, and update the optimistic
state only after success or revert it in the catch path. In changeAutoLockTime,
do not fire save(autoLock, nextAutoLockTime) as a floating promise; await it or
attach explicit .catch handling so the save failure is surfaced and does not
become an unhandled rejection.
- Around line 147-163: The duration rows rendered by renderItem in
ScreenLockConfigView are returning an unkeyed fragment inside the items.map
loop, which can cause React reconciliation warnings. Update renderItem so the
top-level fragment or wrapper for the List.Item and List.Separator has a stable
key derived from the item identity, using the existing item fields in IItem and
keeping the key on the root element returned from the map.
- Around line 93-100: The save flow in ScreenLockConfigView should not silently
succeed when serverRecord.current is missing. In the save function, replace the
optional update on serverRecord.current with a guard that fails fast or
explicitly loads the record before entering database.servers.write, so the save
only completes after a valid record is available. Use save and
serverRecord.current as the key symbols when fixing this path.

---

Nitpick comments:
In `@app/stacks/InsideStack.tsx`:
- Line 101: The ScreenLockConfigView screen registration is masking its props
contract by casting to any, which defeats TypeScript safety. Update the
ScreenLockConfigViewScreen declaration in InsideStack.tsx so it preserves the
StaticScreenProps<undefined> component type without an any cast, and adjust
ScreenLockConfigView if needed so its declared props match the expected screen
contract.